Integrated Environment for Embedded Systems Development IEESD-2000 M.Dolinsky Gomel Fr.Scaryna State University, Belarus dolinsky@gsu.unibel.by Abstract This paper describes an integrated environment for embedded systems development -- IEESD-2000. The following main advantages of IEESD-2000 are presented below: full support of the design path from ideas to their realization in hardware and software; maximum re-use of system's and application software as well as hardware models; powerful tools for fast creation of new system software and hardware models; productive tools for codesign of hardware and application software of embedded systems. In addition, examples of successful application of IEESD-2000 are given. Index Terms: embedded system, hardware, system software, application software, microcontroller, microprocessor, simulator, IDE, compiler, assembler, tuning for target architecture, design. Introduction Embedded systems are an important and quickly growing part on the new computer technologies market. The basic concern of the embedded systems designers is the decreasing of the development time as well as cutting down both the cost of embedded systems design and mass production. The main problem of the embedded systems designers is that they need to develop hardware as well as system and application software simultaneously. At the same time the commercially available products do not provide effective means for embedded systems development from the early stages of the project the whole design cycle. Late hardware and application software integration in embedded system development results in late error detection and finally raises design cost and delays product issue. Analysis of tools for embedded systems development shows there are 3 classes of such tools: 1) Systems for application software development based on concrete microprocessor / microcontroller (MP/MC) or some MP/MC family. In few cases such tools allow codesign of the application software with hardware. Example of such tool is Visual DSP from Analog Devices which allows to develop embedded systems based on ADSP-2106x family [11]. 2) Powerful tools for hardware development from ideas to its realization, but the application software is not simulated in such systems. These are vended by Mentor Graphics, Cadence, Synopsis [8-10]. 3) Systems for codesign and cosimulation of hardware and application software, but only at the system level, or for a specific class of embedded systems. Examples of such tools are Rapide [14], HyTech [15]. So there are following major flaws of the modern tools for codesign of the embedded systems: 1) Absence of codesign support through whole design cycle from ideas to hardware and software realization. Tools of different vendors are used to work on the different stages of the design. Moreover, in many cases, developers skip the first stages of codesign that implies late error detection with the design cost and time-to-market increasing. 2) Weak support of system and application software reuse as well as hardware device models. We give two examples (A and B): A. To develop an embedded system designers need to simultaneously use system software (compiler, assembler, ...) as well as simulate application software, hardware, and external environment of the embedded system - often with separate tool for each task. But how to synchronize the models with a common model time? And how to transmit the simulation result from one system to another? B. In general, the integrated environment for embedded systems development can have fixed number of features that don't depend on developing embedded system's software and hardware models. So these functions can be delegated to so called command center that would integrate any particular specialized tools for codesign and cosimulation of the new embedded systems. 3) Absence of tools for new system software creation (C-compilers, assemblers / disassemblers, compilers for special problem-oriented languages) integrated to commercial available tools for embedded systems development. So, from the one hand, start of new project based on other target architecture implies the substitution of all using system software and simulation tools. From the other hand, designers can't use problem-oriented programming languages because they are forced to use languages and tools which they can buy. In addition, tools for system software creation for new target architectures would cut time to produce system software for new MP/MC and their modifications. 4) Discrepancy of debugging features of modern tools for embedded systems codesign with the state and level of debugging features of modern software IDE. From the number of reasons for this we point to the two base ones: A. Most of commercially available systems have been under development many years so they contain millions of source code lines that slow such systems serious modifications, moreover, it may be impossible to do any modifications at all. B. Quickly developing new microelectronic technologies (MP/MC, ASIC, PLM) imply a new tools development so there are no time to improve existing systems. At the same time since 1997, System Programming Research Lab at Gomel State University, Republic of Belarus makes its own research on complex embedded systemsdesign. This work implies creation of Integrated Environment for Embedded System Development IEESD-2000 that is oriented to full support of embedded system;s design path from ideas to its realization in hardware and software; provides maximum reuse of system and application software as well as models of hardware devices; includes powerful tools for fast creation of new system software and models of hardware; optimizes the process of codesign, cosimulation and codebugging of the embedded system's application software and hardware. The advantages of IEESD-2000 [1-7] via analogues [8-17] are described below. 1. Full support of Embedded Systems design path from ideas to its realization in hardware and software 1.1. Tools for creation, simulation, and documentation of embedded system design The embedded systems design cycle is supported on all design stages from system level to register transfer level. The result of the embedded system software development is the set of programs, written on C, assembler, and/or on any problem oriented programming language developed by user (IEESD-2000 presents to users means for compiler and debugger development for user-defined languages). The result of the embedded system hardware development is synthesizable VHDL description of the hardware or/and EDIF description of hardware boards, including separated electronic components as MP/MC, buffers, DAC/ADC, indicators, etc. Resulting hardware descriptions may be used in CAD systems of lower level to produce real hardware. Additional product of such integrated codesign of the embedded system hardware and software development is full set of tests for the embedded system. The tests may be used when hardware sample would be tested. Moreover, having such a full and exact model of the embedded system, designers can use it to develop set of control and diagnostic tests that may be used in the embedded systems mass product testing. Event-driven modelling with level of adequacy controlled by user provides high simulation rate. There are means for automatic documentation of the project. 1.2. Connection with hardware synthesis tools via input languages of lower level CAD Historically, CADs in digital electronics are developed "bottom-up". I.e. the CADs designers spent the most of efforts on topology design automation to solve the manufacture tasks. As microelectronics are continuously developing and elemental base is constantly improving, the topology design automation will be polished up as well. To pass the models that have been developed earlier to this new technologies there are standard hardware device description languages such as VHDL and EDIF. IEESD-2000 can generate such low-level description of designed embedded system's hardware providing "seamless" top-down design. 1.3. Natural debugging of the designing embedded system's application software, hardware, and external environment interacting The multitasking approach is used in our system.The application software, hardware, and external environment of the designing embedded system are simulated in parallel and the IEESD-2000 provides common simulation time for all model components. User can choose the level of hardware and software model adequacy to cut the time for error founding. At the last stage of the design user can use the full test set, execute software, and simulate hardware with syntesizable VHDL or EDIF description to provide maximum model adequacy. 1.4. Using of instrumental computer for full simulation of the external environment of designing embedded system As a rule, embedded system gets some values as input (for example, data from transducers of temperature, pressure etc.) and elaborates some values as output (for example, data for motor control). To fully prove the embedded system design correctness simulation environment must transmit this values between the embedded system and its external environment. In IEESD-2000 user can create the external environment model in the same way as application software or hardware models as well as to use any other modern software system on instrumental computer (IBM PC) for example, Delphi, C++, Visual Basic. Data exchange between the models of application software, hardware, and external environment may be done via port, file or special memory domain on IBM PC. 1.5. Means to provide communication of developing embedded system's model with the real external environment Evidently, the more exactly the model of the external environment corresponds to the behavior of the real external environment the more errors would be detected and removed from the design on the simulation stage. The ideal case - to embed the design model immediately into the external environment. For example, if the developing embedded system is apparatus controlled by key buttons and which displays information to users by indicators, IEESD-2000 allows to simulate the apparatus key buttons by IBM PC keyboard buttons as well as the apparatus indicators by special windows on IBM PC screen. If additional information is received by embedded system via some additional digital or/and analog channel, IEESD-2000 provides this processes' simulation by files or by user interacting with the embedded system's model. Moreover, IEESD-2000 offers special APIs for information exchange between model of the embedded system and ports of instrumental IBM PC. So if user provides information exchange between ports of instrumental IBM PC and real external environment of the developing embedded system then model of the embedded system could operate in the real external environment. 1.6. Multi-level and heterogeneous modelling The useful feature of multilevel modelling in IEESD-2000 is the possibility to turn " model level" for any hardware fragment between "behavioral" and "structural" models. In this context, "behavioral" model is a model that was produced by any programming system (Delphi, Visual C++, Visual Basic) that allows to build DLL (dynamic linking library).Also "behavioral" model may be written on VHDL (synthesizable or behavioral as well). The "structural" model is a model that was done by composition of other lower-level models. Moreover, the user can mark that some hardware fragment models will be executed by "immediately hardware way". In such a way the user gets possibility to test the hardware fragment without waiting for other hardware parts to be produced. Such process when a part of the hardware is emulated and the other parts of the embedded system are simulated we call "heterogeneous" modelling. To provide heterogeneous modelling IEESD-2000 includes special APIs supplying input information to the hardware fragment and receiving output information from the one in a time pointed by IEESD-2000. This process exactly mathes the way hardware fragment would be simulated. There are some special APIs to provide simulation / emulation of MP/MC used in embedded system. 1.7. Comparative simulation of different level models of the same hardware fragment The well known way for complex system design is "top-down" design. This way is especially efficacious if user can create the model for high level representation as well as for lower level one. For example, behavioral model of the hardware fragment one can use to specify the hardware fragment's algorithm as well as to prepare powerful set of tests that would prove correctness of the design. Let user have done the next level of specification of the hardware fragment - block diagram. IEESD-2000 has the mode, called "comparative" simulation that provides parallel simulation of both models with the same input and output data comparing to prove the adequacy of the models or to find unadequacy errors. 1.8. Same tests used through the whole design cycle At first, the same tests one can use for different levels of model. Moreover, from high-level model tests one can generate tests for lower level models. We explain it on the following example. Let we create the behavioral model M1 and powerful set of tests T1 for it. Further, we decompose M1 to { M11, M12, ..., M15} with functional blocks M11, M12, ..., M15 and achieve that M1 and the composition {M11, M12, ..., M15} are equivalent on the set of tests T1. IEESD-2000 allows to store simulation results for functional blocks M11, M12, ..., M15 as their own test sets T11, T12, ..., T15. In such a way, the chief designer can order development of lower level models (may be synthesizable models) for M11, M12, ..., M15, and (what is remarkable!) he can supply the powerful test sets T11, T12, ..., T15 to prove the new models adequacy. The next important feature of IEESD-2000 is the possibility to simulate models M11, M12, ..., M15 on the levels chosen by user when he extends first test set from T1 to T2. Finally, all developed tests may be used not only to test hardware design but also to organize control and diagnostic testing of the embedded system mass production. 1.9. Means for hardware "synthesizable" description generation The final stage of the hardware design in IEESD-2000 is generation of its VHDL or EDIF description. The description can be passed to lower level CAD tool that will produce the real hardware. 1.10. Means for VHDL tests generation User can initiate generation of the tests' VHDL-description to use it for proving the generated VHDL-model adequacy in other VHDL simulators (of lower level CAD, for example). 1.11. Embedding external synthesis system User can loanch an external synthesis system from within the IEESD-2000 and get and correctly elaborate "back annotation" files describing delays on logical gates.. 2. Maximum re-use of system and application software and models of hardware devices 2.1. Means for embedding the system software from third parties Importance of embedding the system software (compilers, assemblers, object libraries, and converters) from the third parties into IEESD-2000 is defined by existence of means for development and embedding MP/MC models as DLLs into IEESD-2000. User can also define complexity level of the simulator - from instruction-accurate to cycle- accurate. Note that this efforts take not more than 1 man-week for such MC as Intel 8051 (on instruction-accurate level). As the DLL integrated into IEESD-2000 is oriented onto machine code execution and debugging designer can use the third parties' system software for creation of machine codes. User can create own system software in IEESD-2000 as well. This opportunity is described in the next section. To embed compiler/assembler into IEESD-2000 means to provide user with the possibility to work in turbo-mode where the embedded compiler is used transparently for user. There are special APIs allowing IEESD-2000 to work with the program listing and debug information created by the compiler/assembler. Using this APIs, one can create DLL for the compiler/assembler after what IEESD-2000 would start compilation. If there are compilation errors they may be elaborated in Pascal style (to point to the first error line) or in C-style (to form full errors list and to allow user walk from any detected error to its source line). If there are not compilation errors the application program is linking and (if there aren't the linkage errors) debugging is started. To embed linker/object library/converter means to develop special DLL interacting with IEESD-2000. Some of the DLL functions are used to provide user with the interactive definition of the software parameters, another part of DLL is used to provide interaction between IEESD-2000 and embedding components. Converters provide creation the COFF-format of executable files as in IEESD-2000 the program's simulation and execution require COFF format only. Instead of developing DLL for some MP/MC user can embed the MP/MC simulator from the third party. For example, Visual DSP from Analog Devices provides the simulation engine of ADSP 2106x as DLL, isolated from own GUI via series of public APIs [11]. So the engine can be connected into IEESD-2000. After that the user can simulate various embedded systems using ADSP 2106x. 2.2. Support of VHDL models from third parties IEESD-2000 provides simulation of the behavioral VHDL models as well as synthesizable VHDL models so user can include any VHDL models created by third parties into his design. 2.3. Means for new hardware description languages embedding into IEESD-2000 IEESD-2000 contains the means allowing to embed new hardware description languages. It may be used to include models of hardware devices developed with these new hardware description languages. 3. Tools for fast creation of new system software and new models of hardware devices 3.1. Universal environment for codesign of application software and hardware One of the base targets of IEESD-2000 is to minimize the designers' efforts to include in their embedded systems new hardware devices (MP/MC, ASIC, PLIC etc.) based on new microelectronic technologies as well as new system and application software. In general, the new hardware devices may be divided into 2 large groups: 1) ASIC and PLIC, based on new technologies 2) new MP/MC As for all devices from the first group, manufacturers provide them with synthesizable VHDL as input language so all such devices may be used in IEESD-2000. As for second group (MP/MC), IEESD-2000 provides APIs for creation and/or embedding the simulation engines into itself so one would get the modern IDE for cosimulation and codebugging of the application software and hardware of the embedded system. As this IDE of IEESD-2000 does not depend on any MP/MC, so its debug possibilities can be developed faster and independently from any core. So it not only includes the best features from analogues but also has many useful features that are absent in analogues.More detail descriptions of the features is given in the section 4. 3.2. Means for developing and embedding MP/MC simulation engine IEESD-2000's debugging environment interacts with simulation engine of the concrete MP/MC via special interface opened for users and organized as DLL. So to develop the MP/MC simulation engine one can use any programming system allowing to build DLL, for example, Delphi, C++, or Visual Basic. IEESD-2000 documentation contains special data sheet "Technology for MP/MC simulation engine development" as well as examples of i8051.DLL and i8086.DLL elaborated with Delphi. Moreover, IEESD-2000 includes tools, allowing to store technical information about MP/MC architecture, instruction set, peripherals into special data base. This data base may be used to generate instruction-accurate DLL-model of the MP/MC and on-line help. Input of correct test examples for the MP/MC instruction execution from its data sheet allows not only to include it into help but also prove the DLL-model correctness. These tools allow designer to embed simulation engines from third parties such as ADSP 2106x from Visual DSP famoly[11]. 3.3. System software that may be tuned to target architecture To develop software more effectively it is proposed C-compiler with tune possibility to target architecture. The compiler core consists from components responsable for compiler interface, preprocessor, lexical and syntax analysis, system for abstract processor resource control, and general scheme for code generation. Tuning created by developer provides realization of ANSI C primitives according to target processor. In this context C-primitives are operations, operators, declarations and functions. Tuning is the set of C-functions, that are called by C-compiler core to generate C-primitive's realization on target architecture assembler. Adequacy of compiler tuning is guaranteed by existence of full set of tests for C-compiler from the one side, and tool's test feature that automatically simulates all compiled into assembler C-tests with automatic proving of the tests results, from the other side. Time expense for tuning to new architecture is not more than 1 man-month. Universal assembler - disassembler is a software tool that provides possibility to define synonymous accordance between assembler mnemonics and machine codes of target architecture as well as process this information to put it to internal representation for two independent utilities: assembler and disassembler. Time expense for tuning to new architecture is not more than 1 man-week. Optimizer includes modules which can perform all known optimizations on assembler code. The user describes the features of the concrete MP/MC architecture allowing to use some optimization. IEESD-2000 generates the optimizer for defined architecture with all available optimization. 3.4. Means for creation of compilers for special programming languages Means for creation of compilers for special programming languages include 4 tools: 1) Syntax analyzer for programming languages that may be defined as language with context free grammar. This tool generates internal representation of architecture independent "analysis tree" of the source program. 2) Architecture independent optimizer of "analysis tree" 3) Draft code generator tuning to target architecture 4) Optimizing code generator tuning to target architecture 3.5. Means for creation of incremental system software IEESD-2000 has the special APIs evoking after any key button pressing or after some key button pressing or in case of special states (wait state IDLE on IBM PC, for example). Additionally there are APIs to work with the source texts edited in IEESD-2000. These APIs may be used for interacting with incremental compilers that can use given time-slice for compilation continuation. In such a way a large part of the compilation work may be done in "background" mode between user types or modifies the software or reads the help or evaluates variables, etc. 3.6. Means for creation of synthesizable models of hardware with technique of microprogram automata IEESD-2000 allows designer to describe operating algorithm of being designed hardware with powerful microprogram assembler (including full set of arithmetic, logic and shift instructions as well as compare and control instructions) or with special subset of C. The microprogram is debugged in IEESD-2000. Microprogram automa description (on VHDL, for example) may be automatically generate on the base of debugged microprogram. This automation is the union of interacting control and executive devices. 3.7. Means for creation of synthesizable models of hardware by "top-down" design IEESD-2000 provides possibilities for "top-down" design as well as for "bottom- up" design; supports design's hierarchical simulation; gives the number of ways to describe design component models. The process is finished by generating VHDL-descriptions of debugged hardware. 4. Productive separate and complex development of both the application software and the embedded system hardware 4.1. Complex cosimulating and debugging of the application software and hardware IEESD-2000 provides the following possibilities: - parallel (multitasking) cosimulation of hardware (HW), application software (ASW), and external environment (EE) of the embedded system that is synchronized by one from the following events: a) One of the components (HW, ASW, EE) have addressed memory shared with other components (HW, ASW, EE); b) One of the components (HW, ASW, EE) have achieved the time mark pointed by user at the simulation process. User may define this time marks by list, with given time interval, etc.; c) ASW or HW model have accessed port, file, or "virtual" file (special memory domain) for information exchange with EE model or EE itself; d) There is an interrupt from IBM PC keyboard or another interrupt defined by user to simulate EE. At synchronization moments the model times of separately simulated ASW, HW, and EE are compared and models that appear slow get additional time. Note that the means described below may be used in complex simulation as well as in stand alone simulation. 4.2. Stand alone simulation of the application software This section includes description of IEESD-2000's advantages, providing efficacious debugging of the application software. The first such feature is the use of host IBM PC to simulate hardware and external environment of the embedded system. IBM PC keyboard is used to simulate key buttons of designed apparatus as well as to initiate some events in external environment or some behavior of the hardware. IBM PC screen is used to simulate the apparatus indicators as well as to display states of the embedded system or the external environment. IBM PC files as well as interrupts and timer are used to simulate the external environment of the embedded system. IBM PC ports are used to simulate data transmission between host computer and hardware model/emulator. Multitasking of operating systems (Windows 95,98,NT) is used for parallel simulation of application software, hardware and external environment of the embedded system. The next non-traditional possibility is "shadow commands" mechanism. "Shadow commands" begin from comment character so it is transparent for all other tools (assemblers, debuggers). At the same time "shadow commands" are commands for the IDE to do the following useful actions: - to set value into some program variable or memory elements of processor, peripheral or external environment ($S); - to compare two values of some program variable or memory elements of processor, peripheral or external environment ($T) "Shadow commands" $S and $T are very convenient for automatic testing of subroutines and program fragments. In addition, one may organize automatic error localization by setting $T commands in base points of the program; - to set probabilistic value into some program variable or memory elements of processor, peripheral or external environment after each instruction execution or after defined processor cycles. This shadow command maintains probabilistic simulation of external environment (external interruption, for example); Optional non-traditional debug possibility is incremental debug technology. Editor and debugger use the same window with source code. Compilation of the source code is going on while user types or edits his program. As a result transition from editing to debugging and back may be done without any overhead charges. Moreover, the IDE supports "hot start" possibility, i.e. if the user found error while executing program, he may not only correct it at once, but also resume the program execution from any line of the program (as program source code editing does not change values of program variables and processor memory elements, registers, flags etc.). User may restart program execution as well. Additional non-traditional possibility is powerful system for data visualization, including the following facilities: - user definition of enumerated and float-point types for data view (together with standard data view as binary, octal, decimal, hexadecimal, IEEE-float-point numbers; ASCII or EBCDIC characters). - "picture window". Text file is read into the window and any assembler operand, any program variable or any processor memory element may be displayed in any position of that window; - standard debug windows: CPU, On-Chip-Peripherals, "all local variables", "all global variables", "all local arrays", "all global arrays". IEESD-2000 has extended means for source navigation and program executionand usual standard multi-window GUI (menu, window resizing/removing, mouse support, context - sensitive help, colour tuning, service, etc) and comprehensive debug command set. 4.3. Stand alone debugging of hardware models This section includes description of IEESD-2000's advantages, providing efficacious debugging of the hardware models. The first such feature is using of host IBM PC to simulate application software and external environment of the embedded system. IBM PC keyboard is used to simulate key buttons of designed apparatus as well as to initiate some events in external environment or some behavior of the application software. IBM PC screen is used to simulate the apparatus indicators as well as to display states of the embedded system or the external environment. IBM PC files as well as interrupts and timer are used to simulate the external environment of the embedded system. IBM PC ports are used to simulate data transmission between host computer and hardware model/emulator. The next important feature of IEESD-2000 for hardware model debugging is extended means for tests definition such as: merging of tests groups, storing of simulating results as tests; input of test data from ports of host IBM PC as well as from special software executed on host IBM PC. In addition, IEESD-2000 provides extended means for displaying of simulation results such as: enumerated types defined by users for data from pins, buses, registers, counters, RAM, and ROM; data displaying immediately on the scheme using model time navigator. IEESD-2000 includes extended means for model creation such as: DLL-models, microprograms, behavioral VHDL. The last stage of the hardware development is generation of synthesizable VHDL description of the hardware and tests used in the project. 5. Examples of IEESD-2000 application 5.1. Development of the system software for MCs NT8020, DN1630, Intel 8051 The following system software tools for MCs NT8020 and DN1630 (created in New Technology Lab (NTL), Minsk, Belarus) and Intel 8051 were developed with the help of IEESD-2000: C-compilers, assemblers/ disassemblers, simulators and IDE. Emulators for NT8020 and DN1630 were created in NTL and successfully integrated into IEESD-2000. 5.2. Development of hardware-software debug tools for embedded systems based on MC Intel 8051 There were developed own debug tools for embedded system based on Intel 8051. Note, that full model of the hardware and software of the apparatus ANT-97 [5] were debugged with the help of IEESD-2000. At the time ANT-97 is vended in Gomel, Belarus. 5.3. Development of the real embedded systems based on MCs NT8020, Intel 8051 The following embedded systems were developed using IEESD-2000: 1. Apparatus for remote data gathering from transducers (based on MC NT8020, design group - NTL, Minsk, Belarus) 2. Apparatus for measuring of electric features of liquid (based on Intel 8051, design group - "The Way", Gomel, Belarus). 5.4. Using of IEESD-2000 in education IEESD-2000 now is being used in education process of the Gomel Scaryna's State University. There are the list of courses where IEESD-2000 is applied for labs doing: - "Computers and programming" (1-st year) 1. Base components of computers 2. Assembler for Intel 80x86 - " Foundation on computers" (4-th year) 1. Design of digital devices 2. Microprogramming - "Architecture of computer systems" (4-th year) 1. Development of system software components for new MP/MC 2. Design of embedded systems Conclusion Practical using and application of IEESD-2000 shows the following efficacious directions: (under efficacy criterions we mean cost and time of an embedded system development): - creation of tools for embedded system development based on new MP/MC; - design of embedded systems with complex application software and hardware. IEESD-2000 and its components may be effectively used in education activity. References 1. Dolinsky M.S., Ziselman I.M.,Belotsky S.L. Debugger-interpreter with tune possibility //Moscow, Programming.1995. No.6,p.36-45 (In Russian) 2. Dolinsky M.S., Ziselman I.M., Belotcky S.L. "Tools for high-level designing of microprocessors and MP-systems", // Electronics, Sankt-Petersburg, 1996, No 4, p.51-59 (In Russian) 3. Dolinsky M.S. "Methods and tools for high-level designing of embedded hardware- software systems", Riga, "Automatic control and computer sciences", 1997, No 5, p. 63-70 (the journal is translated to English and published in USA) 4. Dolinsky M.S., Ziselman I.M., Harrasov A.A. "Automatical synthesis of microprogram automation", Riga, "Automatic control and computer sciences", 1997, No 5, p. 71-76 (the journal is translated to English and published in USA) 5. Fedortsov €.Ž., Zisselman I.M., Dolinsky M.S. "In-circuit emulator ANT-97", Minsk, "RadioMarket", 1998 £., No 1, p.12-13 (In Russian) 6. Dolinsky M.,Ziselman I.,Belotsky S. "Metalanguage for Peripherals Description and Simulation" Tagungsband 1 des 42. Internationalen Wissenschaftlichen Kolloquiums, Seite 587, ISSN-Nr. 0943-7207 7. Bankowsky V. "Universal Assembler-Disassembler" Tagungsband 1 des 42. Internationalen Wissenschaftlichen Kolloquiums, Seite 141, ISSN-Nr. 0943-7207 8. Bailey B., Leef S. Making the shift toward integrated systems design. //Electronic design / July 8, 1996 p.80-86. 9. George P. Block based design: creating a system on a chip //Electronic design / July 8, 1996 p.86-92. 10. Fernandes P. Moving from RTL to behavioral-level design. //Electronic design / July 8, 1996 p.92-98. 11. Levy M. "Virtual processors and the reality of software simulation" // EDN, 1998, January,15 p.43-49 12. Ladd D.A., Ramming J.C. "A*: A language for implementing language processors" // IEEE Transactions on Software Engineering, 1995, November, Volume 21-11, p.894-901 13. Bagrodia R.L., Liao.W "Maisie: A language for the design of efficient discrete-event simulations" // IEEE Transactions on Software Engineering, 1994, April, Volume 20-4, p.225-238 14. Luckham D.C., Vera J. "An event-based architecture definition language" // IEEE Transactions on Software Engineering, 1995, September, Volume 21-9, p.717-734 15. Alur R., Henzinger T.A., Ho P.H. "Automatic symbolic verification of embedded systems" // IEEE Transactions on Software Engineering, 1996, Marchr, Volume 22-3, p.181-201 16. Julio Leao da Silva Jr., Chantal Ykman-Couvreur, Gjalt de Jong, Bill Lin, Hugo De Man A System Design Methodology for Telecommunication Network Applications. Proceedings.Great Lakes Symposium on VLSI, Urbana-Champaign, Illinois, 1997, p. 64- 69. 17. Sergio D'Angelo, Lauro Mantoani, Riccardo P.G.Mazzei, Stefania Russo, Giacomo R.Sechi. Modular Design of Communication Node Prototypes. Proceedings. Great Lakes Symposium on VLSI, Urbana-Champaign, Illinois, 1997, p. 170-175.